Gestionnaire d’alertes Unijob

Sous Windows et Linux, un gestionnaire d'alertes pour UniJob est inclus dans UVMS.

Chaque DUAS dispose de son propre service d'alertes (automate ALERT). Cette section ne concerne donc que les alertes UniJob.

Le service d'alertes d'UniJob applique les Règles d'alertes pour filtrer les événements locaux. Les événements accumulés sont envoyés à la base de données d'UVMS à chaque cycle de vie (60 secondes par défaut).

Le service d'alertes d'UVMS fournit une notification lorsqu'il reçoit des événements concernant :

• Un service démarré ou arrêté
• Un statut de job correspondant à une règle d'alerte.

Le service d'alertes d'UVMS n'est pas démarré automatiquement au démarrage d'UVMS. Ce comportement est modifiable dans les Paramètres nœud du Management Serveur, catégorie Services optionnels : "Activer le gestionnaire d'alertes". Reportez-vous au Manuel utilisateur d'Univiewer. Cette modification n'est prise en compte qu'au redémarrage d'UVMS.

Lorsque le gestionnaire d'alertes démarre, il se connecte à tous les serveurs d'IO UniJob qu'UVMS doit superviser.

Seules les alertes UniJob sont affichées dans le Tableau de bord des alertes, détaillé dans le Manuel utilisateur d'Univiewer. Les événements sont filtrés sur chaque UniJob par les Règles d'alertes. Les événements sélectionnés et les alertes correspondantes sont stockés dans la base de données d'UVMS.

Le service d'alertes d'UniJob transmet un signal de vie à une fréquence définie par le Paramètre nœud du Management Serveur, catégorie Paramètres des alertes : "Fréquence du ping UniJob". La valeur par défaut est de 60 secondes.

Si aucun signal de vie n'est reçu par UVMS dans un délai : "Fréquence du ping UniJob" x 1,5 (soit 90 secondes par défaut), UVMS considèrera que le nœud UniJob est injoignable. Les événements UniJob filtrés sont accumulés et transmis avec le signal de vie.

Conséquences des performances du gestionnaire d'alertes

Pour des raisons de performances le nombre d'alertes de la base de données doit être inférieur à 100 000. Le cycle de rétention de la purge de la base de données détermine le nombre de données conservées dans la base de données.

Le cycle de rétention par défaut est de 14 jours (défini par le paramètre Durée de rétention des alertes dans les Paramètres nœud du Management Serveur, catégorie Purge). La façon dont les Règles d'alertes sont configurées détermine le nombre d'alertes générées. Par exemple, la sélection de tous les changements d'état des jobs va générer beaucoup plus d'alertes que la seule sélection de l'état Incidenté.

Afin de maintenir l'occupation de la base de données à un niveau acceptable, l'administrateur peut ajuster la Durée de rétention des alertes et les Règles d'alertes. La formule présentée ci-dessous devrait vous aider à déterminer la Durée de rétention des alertes :

Durée de rétention des alertes = 100 000/nombre moyen d'alertes par jour

Reportez-vous à la section "Purge en ligne" pour les détails sur la configuration de la purge.

Le tableau ci-dessus indique que la durée de rétention nécessaire pour maintenir la base de données à moins de 100 000 alertes dépend du nombre de nœuds et du nombre moyen d'alertes par nœud. Le nombre d'alertes peut être réduit en réduisant le nombre et la portée des Règles d'alertes.